Analyzing product portfolios

ABSTRACT

Methods, systems, and computer programs for analyzing product portfolios are described. In one aspect, demand data, lead time data, and inventory data are received for a product portfolio comprising a set of finished products manufactured from a set of associated parts. A measure of inventory cost is computed for the product portfolio as a whole. A measure of order responsiveness is computed for the product offering as a whole. A report evaluating the product portfolio based on the computed measures of inventory cost and order responsiveness is presented.

BACKGROUND

Asset managers of large manufacturing enterprises, for example, computermanufacturers, electronics manufacturers and auto manufacturers, mustdetermine the inventory levels of components and finished products thatare needed to meet target end customer service levels (i.e., thefraction of customer orders that should be received by the requesteddelivery dates). For such manufacturing enterprises, the delivery of afinished product to an end customer typically involves a complex networkof suppliers, fabrication sites, assembly locations, distributioncenters and customer locations through which components and productsflow. This network may be modeled as a supply chain that includes allsignificant entities participating in the transformation of rawmaterials or basic components into the finished products that ultimatelyare delivered to the end customer.

Manufacturers face many pressures, such as competitive markets,leapfrogging technology, price erosion, and demand uncertainty. Withless differentiation between product functionality among vendors, theability to attract customers is often seen as being increasingly tied toservice levels and product options. As a result, manufacturers often aredriven to increase the number of product offerings, or “fan-out”, and tohave all products highly available at the point of sale.

However, increasing product fan-out comes with the downside ofincreasing production planning costs and inventory costs. For example,demand variability requires higher stocking levels in order to ensureproduct availability and, therefore, total inventory targets must bemultiplied by the number of product offerings to ensure that allproducts are in stock as needed. A penalty also comes at the productend-of-life, when unsold units lose value and must be written off orsold at a steep discount.

Manufacturing enterprises must arrange for the delivery of componentparts and other resources that are needed to produce the finishedproducts that are delivered to end customers. Production planners setinventory levels, capacity levels, and manufacturing build plans forfinished products based on various forecasts that are generated for eachproduct offering. For production planners, more product offerings meansmore products to forecast, more inventory to stock, and a greater riskof stock-outs.

Production planning organizations, such as sales, marketing, andfinance, often have the most knowledge of the risks and uncertaintiesassociated with the supply chain. Thus, such organizations are bestpositioned to manage procurement risks and uncertainties. Productionplanners, however, often do not have much input into the decisionsregarding the number of products to offer. In addition, hitherto,production planners have not had the metrics needed to evaluate andcompare different product portfolios and, therefore, could noteffectively communicate the tradeoffs between different productportfolios that might justify reducing the number of product offeringsin a current product portfolio.

SUMMARY

In one aspect, the invention features a machine-implemented method ofanalyzing product portfolios. In accordance with this inventive methoddemand data, lead time data, and inventory data are received for aproduct portfolio comprising a set of finished products manufacturedfrom a set of associated parts. A measure of inventory cost is computedfor the product portfolio as a whole. A measure of order responsivenessis computed for the product offering as a whole. A report evaluating theproduct portfolio based on the computed measures of inventory cost andorder responsiveness is presented.

The invention also features a product portfolio analysis machine and aproduct portfolio analysis computer program for implementing theabove-described procurement risk management method.

Other features and advantages of the invention will become apparent fromthe following description, including the drawings and the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram of an exemplary supply chain that includes afirm that sells to one or more customers finished products manufacturedfrom parts received from one or more suppliers and a spot market.

FIG. 2 is a diagrammatic view of an embodiment of a product portfolioanalysis system 10 that includes a product portfolio analyzer and adatabase.

FIG. 3 is a flow diagram of an embodiment of a method of operating theproduct portfolio analyzer embodiment of FIG. 2.

FIG. 4 is a block diagram of data flow in an implementation of themethod of FIG. 3.

FIG. 5 is a flow diagram of an embodiment of a method of generating andevaluating a baseline product portfolio.

FIG. 6 is a diagrammatic view of the fields in an implementation of aninventory table.

FIG. 7 is a diagrammatic view of the fields in an implementation of anorders table.

FIG. 8 is a diagrammatic view of the fields in an implementation of astock keeping number (SKU) table.

FIG. 9 shows an exemplary order aging curve.

FIG. 10 is a diagrammatic view of an implementation of a baselineevaluation report.

FIG. 11 is a diagrammatic view of an implementation of a performancereport.

FIG. 12 is a diagrammatic view of an implementation of an overstockedfeature performance report.

FIG. 13 is a flow diagram of an embodiment of a method of analyzing aproduct portfolio scenario.

FIG. 14 shows an embodiment of a graphical user interface for receivinguser input defining a product portfolio scenario based on a modificationof a baseline product portfolio.

FIG. 15 shows the graphical user interface shown in FIG. 14 displaying alist of SKUs in the baseline product portfolio of a selected type and alist of potential replacement SKUs.

FIG. 16 shows the graphical user interface shown in FIG. 15 after a userhas designated the substitution of one of the potential replacement SKUsfor one of the SKUs in the baseline product portfolio.

FIG. 17 shows the graphical user interface shown in FIG. 16 after theuser has designated several substitutions of potential replacement SKUsfor corresponding ones of the SKUs in the baseline product portfolio.

FIG. 18 shows the graphical user interface shown in FIG. 17 displayingmetrics comparing the baseline portfolio and the designated productportfolio scenario.

DETAILED DESCRIPTION

In the following description, like reference numbers are used toidentify like elements. Furthermore, the drawings are intended toillustrate major features of exemplary embodiments in a diagrammaticmanner. The drawings are not intended to depict every feature of actualembodiments nor relative dimensions of the depicted elements, and arenot drawn to scale.

I. Operating Environment

Referring to FIG. 1, in one illustrative embodiment, a simplifieddistribution system (or supply chain) 10 includes a set of customers 12expressing cumulative demand levels for a particular set of finishedproducts 14 that drive the production of those finished products 14. Thefinished products 14 are produced by a firm 16 that sells the finishedproducts 14 to customers 12 directly. In other implementations, the firm16 also may sell products 14 to customers 12 indirectly through a supplychannel that includes distributors (or resellers), retailers, andvalued-added resellers. The firm 16 may include a manufacturing linethat is configured to assemble the finished products 14 from componentparts 18 (or raw materials) that may be supplied directly from one ormore component part suppliers 20 or indirectly through a spot market 22.

In operation, end customer demand drives orders, which are satisfied byshipments of the finished products 14 from inventories. Productionplanners for firm 16 schedule the delivery of the finished products 14so that the inventory levels are sufficient to cover both expected endcustomer demand and uncertainty in end customer demand. In general,various demand forecasting techniques may be used to project futuredemand by end customers 12 for the finished products 14.

The finished products 14 typically are grouped into product portfolios24, each of which contains a respective group of closely-relatedfinished products 14 that have similar features and, oftentimes, aremanufactured from many of the same component parts 18. The productportfolio analysis embodiments described in detail below enableproduction planners to evaluate and compare different productportfolios. In this way, these embodiments allow product planners toeffectively communicate the tradeoffs between different productportfolios that might justify reducing the number of product offeringsin a current product portfolio and, thereby, reduce production costs andcomplexity.

II. System Overview

FIG. 2 shows an embodiment of a product portfolio analysis system 30that includes a product portfolio analyzer 32 and a database 34. Thedatabase 34 stores demand data, lead time data, and inventory data forthe finished products 14 in the product portfolios 24 and the associatedcomponent parts 18. The product portfolio analyzer 32 includes agraphical user interface 36 and a calculation engine 38.

The graphical user interface 36 provides a convenient and efficient wayfor a user 40 in an organization, such as sales, marketing, finance orprocurement, to enter data into the product portfolio analyzer 32, tovisualize a product portfolio against multiple metrics, to generateproduct portfolio scenarios, and to run scenarios comparing differentproduct portfolios. The graphical user interface 36 facilitates theuser's interaction with the product portfolio analyzer 32 by providingan efficient interface through which a user may enter inputs 42specifying a baseline product portfolio and product portfolio scenarios,and providing a clean and uncluttered interface for displayingreports/metrics 44 for evaluating a product portfolio reduction strategyalong multiple output metric dimensions.

The calculation engine 38 operates on the data received from the user 40and other data contained within data structures that are stored invarious database tables that are accessible by the product portfolioanalyzer 32. As explained in detail below, calculation engine 38 isoperable to compute one or more metrics for evaluating a productportfolio and for comparing different product portfolios. The graphicaluser interface 36 presents these metrics in one or more productportfolio evaluation reports that enable the tradeoffs between differentproduct portfolio strategies to be visualized and managed.

The product portfolio analyzer 32 may be implemented as one or morerespective software modules operating on a computer. In one embodiment,the product portfolio analyzer 32 may be implemented as a Microsoft®Access® Database utilizing Visual Basic® for Applications (VBA) computerprogram operable as a spreadsheet tool in the Microsoft® Excel®application program, which is operable on a personal computer or aworkstation. In general, the computer (or workstation) includes aprocessing unit, a system memory, and a system bus that couples theprocessing unit to the various components of the computer. Theprocessing unit may include one or more processors, each of which may bein the form of any one of various commercially available processors. Thesystem memory typically includes a read only memory (ROM) that stores abasic input/output system (BIOS) that contains start-up routines for thecomputer, and a random access memory (RAM). The system bus may be amemory bus, a peripheral bus or a local bus, and may be compatible withany of a variety of bus protocols, including PCI, VESA, Microchannel,ISA, and EISA. The computer also may include a hard drive, a floppydrive, and CD ROM drive that are connected to the system bus byrespective interfaces. The hard drive, floppy drive, and CD ROM drivecontain respective computer-readable media disks that providenon-volatile or persistent storage for data, data structures andcomputer-executable instructions. Other computer-readable storagedevices (e.g., magnetic tape drives, flash memory devices, and digitalvideo disks) also may be used with the computer. A user may interact(e.g., enter commands or data) with the computer using a keyboard and amouse. Other input devices (e.g., a microphone, joystick, or touch pad)also may be provided. Information may be displayed to the user on amonitor. The computer also may include peripheral output devices, suchas speakers and a printer. In addition, one or more remote computers maybe connected to the computer over a local area network (LAN) or a widearea network (WAN) (e.g., the Internet).

III. Analyzing Product Portfolios

A. Overview

FIG. 3 shows an embodiment of a method by which the user 40 uses theproduct portfolio analyzer 32 to analyze product portfolios. Inaccordance with this method, the user 40 initially evaluates a baselineproduct portfolio (block 50). Based on this evaluation, the user 40compares the baseline product portfolio to one or more product portfolioscenarios (block 52).

FIG. 4 shows the flow of data into and out of the product portfolioanalyzer 32 during the execution of the product portfolio analysismethod of FIG. 3. In the course of evaluating the baseline productportfolio and the product portfolio scenarios, the product portfolioanalyzer 32 utilizes the demand data 54, the inventory data 56, and thelead time data 58 that is stored in the database 34 to generate abaseline performance report 60 and a baseline evaluation report 62. Theproduct portfolio analyzer 32 uses the demand data 54 and the inventorydata 56 to generate a list 62 of SKUs identifying the finished productsand associated parts in the baseline product portfolio. The user 40 mayenter scenario inputs 66 that specify a product portfolio scenario thatcorresponds to a modification of the list 64 of SKUs. The productportfolio analyzer 32 uses the specified product portfolio scenario andthe demand data 54 to generate a new demand pattern 68 for the specifiedproduct portfolio scenario. The product portfolio analyzer 32 generatesa scenario evaluation report 70 based on the new demand pattern 68.

B. Evaluating a Baseline Product Portfolio

FIG. 5 shows an implementation of the process of evaluating a baselineproduct portfolio (block 50; FIG. 3).

1. Receiving Data For The Baseline Product Portfolio

In accordance with the baseline product portfolio evaluation process,the product portfolio analyzer 32 receives data for the baseline productportfolio (block 72). To this end, the user 40 typically uploads datafrom the database 34 into the product portfolio analyzer 32. This dataincludes demand data 54, inventory data 56, and lead time data 58 forfinished products 14 and the associated parts 18 in the selectedbaseline product portfolio. In some implementations, the uploaded datais stored in the following input table data structures. As used hereinthe terms “items” and “SKU items” refer to respective ones of theindividual finished products 14 and the components parts 18. InventoryTable FIG. 6 shows an exemplary implementation of an inventory table 74that contains periodic (e.g., daily) observations for the finishedproducts and associated parts in the baseline product portfolio. Theinventory table 74 includes the following data fields: Field NameDescription status_date Date on which observation occurred SKU StockKeeping Number for the finished product or component part Qty_OHQuantity on-hand at time observation was made Qty_commit Quantitycommitted for an order at time observation was made Qty_avail Quantityavailable. This value typically equals the quantity on-hand minus thequantity committed SAL_PER_DAY Number of sales that occurred on thisdate (demand)

Orders Table FIG. 7 shows an exemplary implementation of an orders table76 that contains ordering information for the finished products andassociated parts in the baseline product portfolio at different phasesof the product life cycle. The orders table 76 includes the followingdata fields: Field Name Description Order_date Date on which the orderoccurred SKU Stock Keeping Number for the finished product or componentpart SKU_descr Text description of the SKU item PROD_TYPE_Name Name ofthe product type corresponding to the SKU item life_status_CD This fieldindicates the life cycle phase that the SKU item was in at the time thatthis observation was made. Exemplary life cycle phases are DISC -Discontinued. Do not sell. SUST - Mid-Life (sustained). Demand isexpected to continue for the next 8 weeks. EOL - Sales are decreasing.SKU items will be discontinued within the next 8 weeks. QTY Quantityordered

SKU Table FIG. 8 shows an exemplary implementation of a SKU table 78that lists the cost, lead time, and service level for the finishedproducts and associated parts in the baseline product portfolio. The SKUtable 78 includes the following data fields: Field Name Description SKUStock Keeping Number for the finished product or component part CostCost of this SKU item Descr Text description of the item TypeUser-defined values used to classify like SKU items. Examples includeprocessors, memory, and controllers. LeadTime Average lead time in daysLeadTimeStdDev Lead time standard deviation in days SL Target servicelevel for this SKU item, expressed as a percentage. For example, an itemwith an 85% service level would have a value of 0.85 in this field

2. Computing Metrics For Evaluating The Baseline Product Portfolio

Referring back to FIG. 5, after the data for the baseline productportfolio has been received (block 72), the product portfolio analyzer32 computes metrics for evaluating the baseline product portfolio (block80). Among the metrics computed by the product portfolio analyzer 32 area measure of inventory cost for the baseline product portfolio as awhole and a measure of order responsiveness for the baseline productportfolio as a whole.

In general, the inventory cost measure may be any measure thatsubstantially reflects the cost of carrying inventory for the baselineproduct portfolio as a whole. In the illustrated embodiment, theinventory cost measure is the total dollar mount of inventory for allfinished products in the baseline product portfolio that should becarried to meet a target service level given historical order patterns(demand variability). To compute this inventory cost measure, theproduct portfolio analyzer 32 computes a target inventory level (I_(i))for each of the finished products in the baseline product portfolio andeach of the associated parts 18 in accordance with equation (1):$\begin{matrix}{I_{i} = {\frac{\mu_{D}}{2 \cdot {df}} + {k \cdot \sqrt{\left. {{\mu_{D}^{2} \cdot \sigma_{L}^{2}} + {\left( {\mu_{L} + R} \right) \cdot \sigma_{D}^{2}}} \right)}}}} & (1)\end{matrix}$The parameter k is a safety stock factor corresponding to the value ofΦ⁻¹(z), where Φ⁻¹( ) is the standard normal inverse function and z isthe service level specified as the probability of meeting all demand inthe review period. The variable μ_(D) is the estimated mean demand,σ_(D) is the estimated standard deviation of forecast error per unittime, σ_(L) is the estimated lead time standard deviation, μ_(L) is theestimated mean lead time, R is the review period, and df is the deliveryfrequency. In equation (1), the factor (μ_(L)+R) corresponds to theexposure period.

The product portfolio analyzer 32 computes the total dollar amount ofinventory C_(TOT) _(—) _(INV) by computing the product of the targetinventory level I_(i) and the average cost C_(i) for a respectivefinished product i or part i, and summing all of the product values overall finished products and associated component parts in the baselineproduct portfolio as follows: $\begin{matrix}{C_{TOT\_ INV} = {\sum\limits_{\forall i}{I_{i} \cdot C_{i}}}} & (2)\end{matrix}$

In general, the order responsiveness measure may be any measure thatsubstantially reflects the responsiveness of the firm 16 in completingorders from customers 12 for all of the finished products 14 in thebaseline product portfolio. Exemplary order responsiveness measuresinclude order cycle time, supplier response time, and material waittime. In the illustrated embodiment, the order responsiveness measure isa material wait time (in days) that corresponds to the maximum time thata specified proportion of orders for finished products in the baselineproduct portfolio will take. The product portfolio analyzer 32determines the material wait time for each of the finished products inthe baseline product portfolio in accordance with equation (4):P(MWT≦T|SL)=1−F _(μ) _(A) _(,σ) _(A)(F _(μ) _(B) _(,σ) _(B)⁻¹(1−SL))  (4)whereμ_(A),σ_(A)=μ_(D)·(μ_(L) +RP),√{square root over (σ_(D) ²·(μ_(L)+RP)+σ_(L) ²·μ_(D) ²)}  (5)andμ_(B),σ_(B)=μ_(D)·(μ_(L) +RP−T),√{square root over (σ_(D) ²·(μ_(L) +RP−TΛ 0)+σ_(L) ²·μ_(D) ²)}  (6)P(MWT≦T|SL) is a measure of the probability of the material to beavailable in T time given that the immediate service level is SL, F(μ,σ)is a cumulative probability distribution with a mean μ and a standarddeviation σ, F⁻¹(μ,σ) is an inverse cumulative probability distributionwith a mean μ and a standard deviation σ, μ_(D) is a mean demand, σ_(D)is a demand variance, μ_(L) is a mean lead time, σ_(L) is a lead timevariance, and RP is a review period length. The operator Λ returns themaximum of the two values on either side of the operator. FIG. 9 showsan exemplary plot of P(MWT≦T|SL) for a given service level (SL). Thisplot typically is referred to as an “order aging curve”. The order agingcurve maps specified proportions of orders that can be completed tocorresponding material wait time values. Thus, for a given probabilityvalue, the material wait time can be determined.

The product portfolio analyzer 32 computes the material wait time forthe baseline product portfolio as a whole by setting the functionP(MWT≦T|SL) in equation (4) to a prescribed probability level (e.g.,90%) and solving for MWT. By determining the MWT values for each of thefinished products in the baseline product portfolio, the productportfolio analyzer 32 may determine the material wait time for thebaseline product portfolio as a whole.

3. Presenting The Computed Evaluation Metrics

As shown in FIG. 10, in some embodiments, the computed measure ofinventory cost and the computed measure of order responsiveness arepresented in the baseline evaluation report 62. The baseline evaluationreport 62 allows the user 40 to compare actual inventory cost and actualmaterial wait time in the baseline product portfolio with the targetlevels for these measures computed by the product portfolio analyzer 32.

In some implementations, the inventory cost and order responsivenessmeasures are computed under the assumption that inventories of all partsare held at the same service levels. In this way, the baselineevaluation report 62 may be used to determine how much better thebaseline product portfolio would have performed in terms of inventorycost and material wait time if the specified target service level hadbeen achieved across all finished products and component parts. In otherimplementations, the user 40 may specified a respective target servicelevel for each of the finished products and component parts in thebaseline product portfolio.

In addition to the baseline evaluation report 62, the product portfolioanalyzer 32 presents one or more performance reports that contain setsof relevant metrics that enable the user 40 to identify candidatefinished products and parts for removal from the baseline productportfolio.

FIG. 11 shows an implementation of the performance report 60 thatperformance report contains, among other parameter values, averageinventory cost (Ave Inv $) and average demand (AveDemand) for each ofone or more finished products and associated parts in the baselineproduct portfolio. In the illustrated implementation, the performancereport 60 includes the following data fields: Field Name DescriptionType This corresponds to the “Type” field in the SKU table 78 Ave Inv $The average dollar amount of inventory for the item. SKU Stock KeepingNumber for the finished product or component part Descr Text descriptionof the item Min I Date First date for which there is inventoryobservation for this item. Max I Date Last date for which there isinventory observation for this item. Min O Date First date for whichthere is order data for this item Max O Date Last date for which thereis order data for this item AveDemand Average demand in units per dayAve Tiv Average inventory in days of supply Cost/Unit Dollar cost perunit for this itemThe “Min” and “Max” data columns are useful for assessing thecompleteness of the product data.

The data that is presented in the performance report 60 may be sorted bythe values in any of the columns. In one implementation, the data aresorted by default in accordance with the values in the Ave Inv $ field.This sorting of the data allows the user 40 to readily identify thoseSKU items that have high average inventory costs. Eliminating these SKUitems from the baseline product portfolio potentially might have thegreatest impact on reducing the inventory cost for the baseline productportfolio as a whole.

The user 40 may identify those high-inventory-cost items that areassociated with relatively low average demand as low-performing SKUitems. In some implementations, the user may set a threshold averagedemand level and those SKU items having an average demand level belowthe threshold level are highlighted in the performance report 60. Forexample, the low-performing SKU item PLK9 is highlighted in theexemplary performance report 60 shown in FIG. 11. Items near the top ofeach product type section of the performance report 60 that also areassociated with relatively low average demand typically are goodcandidates for removal from the baseline product portfolio. As explainedin the following section, the user 40 may shift some or all of thedemand for such high-cost, low-performing SKU items to one or morehigh-performing SKU items in a product portfolio scenario.

FIG. 12 shows an implementation of an overstocked feature performancereport 82 that contains the following data fields: Field NameDescription Type This corresponds to the “Type” field in the SKU table78 Feature The name of the reported SKU item Demand The average dailydemand for each SKU item in the reporting timeframe as enteredpreviously in the start and end date windows StdDev The standarddeviation of the daily demand for each SKU item Cov The covariance ofthe daily demand for each SKU item ADOS The actual days of supply foreach SKU item SL The implied service level for each SKU item. A value of1.00 shows that the inventory level is so high that it is unfeasible tocalculate the implied service level. RDOS Recommended days of supply.Calculated based on a service level of 99.9% and the actual demanduncertainty for the SKU item.The calculation engine automatically computes the implied service levelby solving for the safety stock factor k in equation (1) and thensolving for the service level z=Φ(k), where Φ( ) is the standard normalcumulative distribution function.

The overstocked feature performance report 82 assists the user 40 inidentifying SKU items that have excessive stocking levels and thereforemight be candidates for elimination from the baseline product portfolio.In particular, SKU items that are associated with an unfeasibly highimplied service level typically are associated with excessive stockinglevels. The user 40 can readily identify such SKU items in theoverstocked feature performance report 82 by identifying SKU items withhigh implied services levels (e.g., implied service levels equal to1.00).

In some implementations, the product portfolio analyzer 32 is configuredto present additional reports that assist the user 40 in identifying SKUitems for possible elimination from the baseline product portfolio. Forexample, in some implementations, the product portfolio analyzer 32presents a demand plot showing demand over a planning horizon and aninventory plot showing inventory levels over the planning horizon. Thedemand plot allows the user 40 to identify SKU items having high demandvariability and therefore might be considered as possible candidates forelimination from the baseline product portfolio. The inventory plotallows the user 40 to identify SKU items that are associated withsustained periods of inventory build-up or stock-outs and thereforemight be considered as possible candidates for elimination from thebaseline product portfolio.

C. Comparing the Baseline Product Portfolio to One or More ProductPortfolio Scenarios

FIG. 13 shows an embodiment of a method by which the product portfolioanalyzer 32 analyzes product portfolio scenarios. This method allows theuser 40 specifies different product portfolio scenarios and to comparethe baseline product portfolio to these different in terms of one ormore evaluation metrics. In the illustrated embodiment, the productportfolio analyzer 32 compares different product portfolios in terms ofinventory cost and order responsiveness.

In accordance with this method, the product portfolio analyzer 32initially receives user input defining a product portfolio scenario(block 84). To this end, the graphical user interface 36 presents aScenario Analysis interface window 86, which is shown in FIG. 14. TheScenario Analysis window 86 includes a “Select SKU to substitute” column88 for displaying a list of the SKU items in the baseline productportfolio, a “Select SKU to substitute with” column for displaying alist of SKU items that might be substitute for SKU items eliminated fromthe baseline product portfolio, and a “Substitution list” column 90 fordisplaying a list of the

SKU item substitutions that correspond to the transformation of thebaseline product portfolio to the product portfolio scenario. In theillustrated embodiment, the product portfolio analyzer 32 organizes theSKU items in the baseline product portfolio by SKU item Type, which theuser specifies using a Type input box 92.

In operation, the user 40 selects a SKU item Type (e.g., RAM) from adrop down menu that is associated with the Type input box 92 and listsall of the SKU item Types for the items in the baseline productportfolio. In response, the graphical user interface 36 populates boththe “Select SKU to substitute” column 86 and the “Select SKU tosubstitute with” column 88 with all of the SKU items in the baselineproduct portfolio for which demand data is available. The user 40 thenselects at least one SKU item in the “Select SKU to substitute” column86 and a SKU item in the “Select SKU to substitute with” column 88. TheSKU items selected in the “Select SKU to substitute” column 86 will beexcluded from the product portfolio scenario, and the SKU items selectedin the “Select SKU to substitute with” column 88 are the items that willreplace, in whole or in part, the items being eliminated from thebaseline product portfolio for the purposes of demand substitution. Forexample, in the example shown in FIG. 16, the Scenario Analysis window86 highlights the SKU DDR 1G in the “Select SKU to substitute” column 86and highlights the SKU DDR 1024M in the “Select SKU to substitute with”column 88 to reflect the user's indication to substitute SKU DDR 1G withSKU DDR 1024M in the product portfolio scenario.

The user 40 also enters a demand multiplier value between 0 and 1 in aMultiplier input box 94. The demand multiplier value specifies theproportion of demand to shift from the item eliminated in column 86 tothe selected target items in column 88. For example, a multiplier valueof 1.00 corresponds to movement of 100% of the demand, whereas amultiplier value of 0.8 corresponds to movement of 80% of the demand. Ademand multiplier value of 0 indicates that the SKU item that isselected in the “Select SKU to substitute” column 86 is to be eliminatedfrom the product portfolio scenario with no demand substitution. TheScenario Analysis window 86 also allows the user 40 to split demand foreliminated items among multiple replacement items.

After each demand substitution has been specified by the user 40, theuser selects the arrow button 96, which causes the demand substitutionto be listed in the “Substitution list” column 90, as shown in FIG. 16.Referring to FIG. 17, after the user 40 has finished specifying a set ofSKU items to be eliminated from the baseline product portfolio and theSKU items that will replace the eliminated items in the productportfolio scenario, the user 40 selects the Run button 98.

Referring back to FIG. 13, the calculation engine 38 computes metricsfor evaluating the product portfolio scenario in response to the user'sselection of the Run button 98 (block 100). Among the metrics computedby the calculation engine 38 in the illustrated embodiments are ameasure of inventory cost for the product portfolio scenario as a wholeand a measure of order responsiveness for the product portfolio scenarioas a whole. In this process, the calculation engine 38 derives the newdemand pattern 68 (shown in FIG. 4) for the product portfolio scenariobased on the demand data 54 and the demand substitution inputs receivedfrom the user 40. In particular, the demand data 54 for the substituteditems is scaled by the demand multipliers specified by the user 40 toobtain the demand for the specified replacement items in the productportfolio scenario. The resulting demand pattern then may be used tocompute the measures of inventory cost and order responsiveness for theproduct demand scenario in the same manner explained above in connectionwith the baseline product portfolio.

The graphical user interface 36 then presents a scenario evaluationreport 70 comparing the baseline product portfolio and the productportfolio scenario (block 102). In the illustrated embodiments, thegraphical user interface 36 presents the scenario evaluation report 70in a results window 104, as shown in FIG. 18. The Inventory area of theresults window 104 shows the expected dollar improvement in the amountof inventory that would need to be held to meet the target servicelevels given historical demand uncertainty by changing from the baselineproduct portfolio to the product portfolio scenario. Positive inventorynumbers indicate the amount of expected inventory cost savings, whereasnegative inventory numbers indicate the amount by which inventory costsare expected to increase. The OCT (Order Cycle Time) area of the resultswindow 104 shows the expected improvement in order cycle time in days bychanging from the baseline product portfolio to the product portfolioscenario. Once again, positive numbers indicate the amount of expectedorder cycle time improvement, whereas negative numbers indicate theamount by which the order cycle time is expected to increase.

The baseline and scenario evaluation reports 62, 70 allow the user toexamine the benefits that are expected to be realized if some productsin the baseline product portfolio are eliminated in favor of others. Inone example, suppose the user 40 ran generated a baseline productportfolio for an 85% target service level and the baseline evaluationreport indicated that the inventory cost should be $100,000 with amaterial wait time of 30.5 days at 90% availability. In addition, assumethat the user 40 specified a product portfolio scenario characterized byan expected inventory cost saving of $10,000 and an order cycle timeimprovement of 10 days. In some implementations, the inventory costimprovement and order cycle time improvement values in the scenarioevaluation report 70 are based on the higher of the actual historicalinventory levels and the invention levels needed to achieve an 85%service level. In effect, this output is the combination of settingidentical service levels across all SKU items as in the baselineevaluation report 62 and reducing the range of product offeringssimultaneously. Therefore, if too much inventory is being carried in thebaseline product portfolio, the scenario evaluation report will revealthe benefits indexed to historical levels for parts identified forsubstitution.

The user 40 may specify multiple product portfolio scenarios and compareeach product portfolio scenario to the baseline product portfolio untila product portfolio scenario representing the greatest improvement ininventory cost savings and/or order cycle time improvement has beenidentified.

IV. Conclusion

Other embodiments are within the scope of the claims. For example, thesystems and methods described herein are not limited to any particularhardware or software configuration, but rather they may be implementedin any computing or processing environment, including in digitalelectronic circuitry or in computer hardware, firmware, or software.

1. A machine-implemented method of analyzing product portfolios,comprising: receiving demand data, lead time data, and inventory datafor a product portfolio comprising a set of finished productsmanufactured from a set of associated parts; computing a measure ofinventory cost for the product portfolio as a whole; computing a measureof order responsiveness for the product offering as a whole; andpresenting a report evaluating the product portfolio based on thecomputed measures of inventory cost and order responsiveness.
 2. Themethod of claim 1, wherein the computing of the inventory cost measurecomprises computing a cost of inventory levels of the finished productsand associated parts needed to cover uncertainty in demand over anexposure period with a target service level.
 3. The method of claim 1,wherein the computing of the order responsiveness measure comprisesdetermining a material wait time corresponding to an expected amount oftime needed to complete a specified proportion of orders for a givenfinished product in the product portfolio with a target service level.4. The method of claim 1, further comprising presenting a portfolioperformance report containing average inventory cost and average demandfor each of one or more finished products and associated parts in theproduct portfolio.
 5. The method of claim 4, wherein finished productsand associated parts are listed in the performance report in order ofhighest average inventory cost.
 6. The method of claim 1, furthercomprising computing implied service levels for respective ones of thefinished products and associated parts in the product portfolio.
 7. Themethod of claim 1, further comprising presenting an overstocked featurereport containing demand, implied service level, actual days of supply,and recommended days of supply for each of one or more finished productsand associated parts in the product portfolio.
 8. The method of claim 1,further comprising receiving user input defining a second productportfolio comprising a second set of finished products manufactured froma second set of associated parts.
 9. The method of claim 8, furthercomprising computing a measure of inventory cost and a measure of orderresponsiveness for the second product portfolio as a whole.
 10. Themethod of claim 9, wherein the portfolio evaluation report presents acomparison of the inventory cost measures and the order responsivenessmeasures computed for the first and second product portfolios.
 11. Themethod of claim 10, wherein the comparison comprises an expecteddifference in inventory cost and an expected difference in order cycletime between the first and second product portfolios.
 12. The method ofclaim 8, wherein the receiving of the user input comprises presenting alist of the finished products and associated parts in the first productportfolio, and providing an interface enabling a user to specifymodifications to the present list to arrive at the finished products andassociated parts in the second product portfolio.
 13. The method ofclaim 12, wherein the interface enables the user to replace designatedones of the finished products and associated parts in the first productportfolio with designated ones of the finished products and associatedparts in the second product portfolio.
 14. The method of claim 13,wherein the interface enables the user to specify a proportion of demandto shift from replaced ones of the finished products and associatedparts in the first product portfolio to designated ones of the finishedproducts and associated parts in the second product portfolio.
 15. Themethod of claim 14, wherein the computing of the inventory cost measurecomprises computing demand data for the second product portfolio basedon the received demand data and the user-specified proportions ofshifted demand.
 16. A machine for analyzing product portfolios at leastone data processing module configured to: receive demand data, lead timedata, and inventory data for a product portfolio comprising a set offinished products manufactured from a set of associated parts; compute ameasure of inventory cost for the product portfolio as a whole; computea measure of order responsiveness for the product offering as a whole;and present a report evaluating the product portfolio based on thecomputed measures of inventory cost and order responsiveness.
 17. Themachine of claim 16, wherein the at least one data processing module isconfigured to compute a cost of inventory levels of the finishedproducts and associated parts needed to cover uncertainty in demand overan exposure period with a target service level.
 18. The machine of claim16, wherein the at least one data processing module is configured todetermine a material wait time corresponding to an expected amount oftime needed to complete a specified proportion of orders for a givenfinished product in the product portfolio with a target service level.19. The machine of claim 16, wherein the at least one data processingmodule is configured to present a portfolio performance reportcontaining average inventory cost and average demand for each of one ormore finished products and associated parts in the product portfolio.20. The machine of claim 19, wherein the at least one data processingmodule is configured to list the finished products and associated partsin the performance report in order of highest average inventory cost.21. The machine of claim 16, wherein the at least one data processingmodule is configured to compute implied service levels for respectiveones of the finished products and associated parts in the productportfolio.
 22. The machine of claim 16, wherein the at least one dataprocessing module is configured to present an overstocked feature reportcontaining demand, implied service level, actual days of supply, andrecommended days of supply for each of one or more finished products andassociated parts in the product portfolio.
 23. The machine of claim 16,wherein the at least one data processing module is configured to receiveuser input defining a second product portfolio comprising a second setof finished products manufactured from a second set of associated parts.24. The machine of claim 23, wherein the at least one data processingmodule is configured to compute a measure of inventory cost and ameasure of order responsiveness for the second product portfolio as awhole.
 25. The machine of claim 24, wherein the portfolio evaluationreport presents a comparison of the inventory cost measures and theorder responsiveness measures computed for the first and second productportfolios.
 26. The machine of claim 25, wherein the comparisoncomprises an expected difference in inventory cost and an expecteddifference in order cycle time between the first and second productportfolios.
 27. The machine of claim 23, wherein the at least one dataprocessing module is configured to present a list of the finishedproducts and associated parts in the first product portfolio and providean interface enabling a user to specify modifications to the presentlist to arrive at the finished products and associated parts in thesecond product portfolio.
 28. The machine of claim 27, wherein theinterface enables the user to replace designated ones of the finishedproducts and associated parts in the first product portfolio withdesignated ones of the finished products and associated parts in thesecond product portfolio.
 29. The machine of claim 28, wherein theinterface enables the user to specify a proportion of demand to shiftfrom replaced ones of the finished products and associated parts in thefirst product portfolio to designated ones of the finished products andassociated parts in the second product portfolio.
 30. The machine ofclaim 29, wherein the at least one data processing module is configuredto compute demand data for the second product portfolio based on thereceived demand data and the user-specified proportions of shifteddemand.
 31. A computer program for analyzing product portfolios, thecomputer program residing on a computer-readable medium and comprisingcomputer-readable instructions for causing a computer to: receive demanddata, lead time data, and inventory data for a product portfoliocomprising a set of finished products manufactured from a set ofassociated parts; compute a measure of inventory cost for the productportfolio as a whole; compute a measure of order responsiveness for theproduct offering as a whole; and present a report evaluating the productportfolio based on the computed measures of inventory cost and orderresponsiveness.
 32. The computer program of claim 31, wherein thecomputer-readable instructions cause the computer to compute a cost ofinventory levels of the finished products and associated parts needed tocover uncertainty in demand over an exposure period with a targetservice level.
 33. The computer program of claim 31, wherein thecomputer-readable instructions cause the computer to determine amaterial wait time corresponding to an expected amount of time needed tocomplete a specified proportion of orders for a given finished productin the product portfolio with a target service level.
 34. The computerprogram of claim 31, wherein the computer-readable instructions causethe computer to present a portfolio performance report containingaverage inventory cost and average demand for each of one or morefinished products and associated parts in the product portfolio.
 35. Thecomputer program of claim 34, wherein the computer-readable instructionscause the computer to list the finished products and associated parts inthe performance report in order of highest average inventory cost. 36.The computer program of claim 31, wherein the computer-readableinstructions cause the computer to compute implied service levels forrespective ones of the finished products and associated parts in theproduct portfolio.
 37. The computer program of claim 31, wherein thecomputer-readable instructions cause the computer to present anoverstocked feature report containing demand, implied service level,actual days of supply, and recommended days of supply for each of one ormore finished products and associated parts in the product portfolio.38. The computer program of claim 31, wherein the computer-readableinstructions cause the computer to receive user input defining a secondproduct portfolio comprising a second set of finished productsmanufactured from a second set of associated parts.
 39. The computerprogram of claim 38, wherein the computer-readable instructions causethe computer to compute a measure of inventory cost and a measure oforder responsiveness for the second product portfolio as a whole. 40.The computer program of claim 39, wherein the portfolio evaluationreport presents a comparison of the inventory cost measures and theorder responsiveness measures computed for the first and second productportfolios.
 41. The computer program of claim 40, wherein the comparisoncomprises an expected difference in inventory cost and an expecteddifference in order cycle time between the first and second productportfolios.
 42. The computer program of claim 38, wherein thecomputer-readable instructions cause the computer to present a list ofthe finished products and associated parts in the first productportfolio and provide an interface enabling a user to specifymodifications to the present list to arrive at the finished products andassociated parts in the second product portfolio.
 43. The computerprogram of claim 42, wherein the interface enables the user to replacedesignated ones of the finished products and associated parts in thefirst product portfolio with designated ones of the finished productsand associated parts in the second product portfolio.
 44. The computerprogram of claim 43, wherein the interface enables the user to specify aproportion of demand to shift from replaced ones of the finishedproducts and associated parts in the first product portfolio todesignated ones of the finished products and associated parts in thesecond product portfolio.
 45. The computer program of claim 44, whereinthe computer-readable instructions cause the computer to compute demanddata for the second product portfolio based on the received demand dataand the user-specified proportions of shifted demand.